System, method and computer program product for provisioning of resources and service environments

ABSTRACT

The present invention provides a system, method, and computer program product to accelerate provisioning by dynamically creating dynamic free pools (DFPs) of pre-provisioned resources that are provisioned in advance, and are ready and free for use. A DFP construct for a resource, and its associated dynamic free pool manager are generated dynamically from a formal description of an aggregated resource structure (e.g. in the form of an XML schema). The present invention also provides a system, method, and computer program product to improve the delivery time of SEs based on the DFP constructs. The methods are extended to deal with special conditions such as contention over resources, or critical delivery time.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the priority benefit, under 35 U.S.C. § 119, ofEuropean patent application 04106885.9, filed Dec. 22, 2004, andincorporated herein by reference.

BACKGROUND OF THE INVENTION

1. Field of the invention

The subject of present invention relates to provisioning of resourcesand service environments (SEs) required for IT service offerings, and inmore particular to an accelerated provisioning of such resources andSEs.

2. Description of the Related Art

In the traditional outsourcing business the customers who want toconcentrate on their core business hand over their IT business or atleast parts of it to service providers who run the IT business forseveral customers. For each outsourced IT business of a specificcustomer the service provider has to provision a specific SE. The termprovisioning of a specific SE as used in the present patent applicationmeans the creation of all resources needed for such an SE, how to managethose resources in order to fulfill the conditions specified for examplein an agreement or the defined IT service offering, how to handlesituations like resource shortages or resource over-provisioning, andthe appropriate assigned resource management actions like configuring orinstalling of said resources. The provisioning is accomplished by usinga “provisioning system” that provides function components necessary toaccomplish such a provisioning. Each IT component within the specific SErepresents a so-called resource.

Prior art provisioning systems create and manage multiple SEs on ashared infrastructure. The infrastructure consists of static free poolsof hardware resources such as servers and storage, network resourcessuch as virtual local area networks (VLANs), switches, and, firewalls,and software resources such as licenses. The SEs that the provisioningsystem creates and manages may pertain to a variety of domains includinge-business services, life-science applications, and on-line gaming. Theprovisioning infrastructure ensures smooth operation of the SE instancesby dynamically reconfiguring the infrastructure to adjust resourceallocation to the SEs.

Provisioning system and the SEs they manage differ in the types ofresources used, the topology of the network connecting them, theservices that are offered, and the business and operational constraintsthat govern their operations.

The provisioning system operates on resources types or parts. Resourcetypes may be basic resource types or aggregated resource types. Anaggregated resource type is a logical resource that is defined as afederation of other related resources (represented by other parts). Anexample of an aggregate resource type, which is represented in a partscatalog, may be a WebSite which federates the following resources:loadBalancer, frontendVLAN, backendVLAN, WebServerGroup, database,firewall. The aggregate resource definition may also include a set ofrelationships needed to be satisfied, e.g. a use relationship betweenthe WebServerGroup resource and the database resource.

The federated resources can be also aggregated resources and/or basicresources. The expansion of an aggregated resource to its federatedresources is a recursive process and results in a tree structure termedtopology tree whose nodes are the resource types, the descendants ofevery node are the resources it federates and the leaves of the tree arebasic resources for which RMs exist.

The structure/definition of an SE can also be represented as anaggregated resource.

A typical prior art provisioning system 10 is shown in FIG. 1. Theprovisioning system normally consists of resource managers (RMs) 60,resource services (RSs), a parts catalog (PC) 40, a planner component(PL) 20, and a runtime engine (RE) 30.

The resource managers (RMs) encapsulate logic to provision and manage aparticular type of basic resource. Resources can be physical (e.g., anxSeries server) or virtual (e.g., a logical partition (LPAR) on azSeries server). A resource may be allocated to a service environment orunallocated (free). Free basic resources (that are not virtual) are keptin a logical structure called a free pool 50. An important function ofthe RM is managing the free pool, including tracking availability ofresources and selecting resources for allocation to a serviceenvironment. In some cases the RMs actually create the resource. Forexample, an LPAR RM may create an LPAR by configuring a zSeries machine.

Resource services (RSs) encapsulate configuration operations that needto be performed on a single resource or a set of resources. Suchconfiguration operations may include switch configuration, installationof software, etc.

The parts catalog includes descriptions of resources and capabilities inthe form of XML definitions termed parts. Parts can represent basicresources for which an RM exists or aggregated resources previouslydefined. Parts may reference other parts, for example, a part for anaggregated resource references the parts for its federated resources.SEs are also represented as aggregated resources for which parts existin the catalog.

A planner component is used to generate, given an SE definition, a setof automation procedures and instructions, termed plans, that includeinvocations of operations on RMs and RSs, and that are used in order toprovision and manage the SE.

Specifically the structure of the SE is defined as an aggregatedresource; from it, the following plans are created: (1) plans toprovision and de-provision (destroy) the SE; and (2) plans to change thecapacity of an SE by changing the number of instances of each of thefederated resources designated as “variable” the definition of the SE.

A runtime engine (RE) is used to execute plans generated by the plannerupon an explicit user request (e.g., a subscription to an SE triggersits provisioning), or upon an internal system event (e.g., a high loadevent can trigger adding Web servers to a Web site SE).

The process of creation of an SE, or changing its capacity, may take asignificant time for the following reasons:

-   -   1. Limited or no control over the time it takes to perform        manual operations.    -   2. Limited or no control over the time it takes to obtain        resources/services from a third-party provider. In particular,        resources may not be available at the time of the request (an        example is obtaining a VPN connection from a third party network        provider which takes approximately two days).    -   3. The process of provisioning aggregated resources from a set        of basic resources is time consuming. In particular, operations        such as installation of software and operating systems, and data        management operations are time consuming and may take several        hours to complete.    -   4. In case of resource contention, resources may need to be        de-allocated from other running SEs; the process involves        deconstruction of aggregated resources and returning the basic        resources to their respective free pools before they can be used        for the new SE. Typical operations may include disk scrubbing to        satisfy a security policy.

SUMMARY OF THE INVENTION

Starting from this, it is object of the present invention to provide asystem, method and computer program product avoiding the disadvantagesof the prior art provisioning systems as described above.

The present invention provides a system, method, and computer programproduct to accelerate provisioning by dynamically creating dynamic freepools (DFP) of pre-provisioned resources that are provisioned in advanceand are ready and free for use. A DFP construct for a resource and itsassociated dynamic free pool manager are generated dynamically from aformal description of an aggregated resource structure (e.g. in the formof an XML schema). The present invention also provides a system, method,and computer program product to improve the delivery time of SEs basedon the DFP constructs. The methods are extended to deal with specialconditions such as contention over resources, or critical delivery time.

The present invention uses in a preferred embodiment a global dynamicfree pool manager (GDFPM). The GDFPM uses decision algorithms allowingone to provision a resource with and without a DFPM, de-provision withor without deconstruction of the resource, and to transfer resourcesbetween SEs. The decision algorithms depend on objective functions, forexample, total revenue of provisioning provider or amortized time forresources to be provisioned.

The decision algorithms may take into account parameters like revenuefor allocation of a resource, penalty if not allocated in time, cost forhaving a resource provisioned, time to provision. The GDFPM reacts tostate change events like creation and deletion of an SE, change ofcapacities of SE, change total number of resources in the system,addition of resource types and SE definitions into the parts catalog.The GDFPM decides on required combination of DFPMs and their assignedDFPs. Furthermore, it manages the set of DFPMs including their creationand their deletion.

The present invention uses in a preferred embodiment dynamic free poolmanagers (DFPMs). The creation and deletion of a DFPM is based on thedecision of the GDFPM by using state change events and decisionalgorithms (policy). The DFPM manages an assigned DFP of aggregatedresources. In a preferred embodiment the DFPM manages also basicresources and third-party owned resources. The DFPM may operate passiveor autonomic based on its policy. In a preferred embodiment, the policyis input to constructor of the DFPM. In a preferred embodiment of thepresent invention, the DFPM extends the interfaces of a resource managerby Create, Delete, ChangeFPCapacity as well as Construct_DFPM andDestruct_DFPM.

The present invention uses in a preferred embodiment dynamic free pools(DFPs). A DFP may be generated in the following cases:

-   -   1. An aggregated resource does not have an RM. If the time to        provision is significant, which may be the case if it requires        time-consuming configuration, then a dynamic free pool may be        generated.    -   2. Today, resources owned by a third party are obtained by        contacting the third party when they are needed for an SE. A DFP        of such resources can be created if the time to obtain the        resource is significant. The cost of holding third-party owned        resources needed to be taken into account in the decision.    -   3. Basic resources are resources for which an RM exists. These        resources are not further partitioned to federated resources by        the provisioning system. (Basic resources in one provisioning        system can actually be complex and treated as an aggregated        resource in other provisioning systems—for example one may think        of a BioGrid RM.) In the case where the RM actually have to        build the resource upon a create request it may make sense to        provision a number of them in advance.

DFPM and their associated DFPs can be constructed and destroyed by theGDFPM dynamically (at runtime). The decision is based on the partscatalog state, and the state of the provisioning system (SE instancesand their state, the state of the DFPs).

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

The above, as well as additional objectives, features and advantages ofthe present invention will be apparent in the following detailed writtendescription.

The novel features of the invention are set forth in the appendedclaims. The invention itself, however, as well as a preferred mode ofuse, further objectives, and advantages thereof, will be best understoodby reference to the following detailed description of an illustrativeembodiment when read in conjunction with the accompanying drawings,wherein:

FIG. 1 shows a prior art provisioning system;

FIG. 2 shows the method steps for provisioning an SE using a priorprovisioning system;

FIG. 3 shows a prior art provisioning system extended by the presentinvention;

FIG. 4 shows an example of an SE with variable federated resources,

FIG. 5 shows the method for creation of a DFPM according to the presentinvention;

FIG. 6 shows the method for deletion of a DFPM according to the presentinvention;

FIG. 7 shows the method how to construct a plan for creation of an SE ora federated resource;

FIG. 8 shows the method how to construct a plan for deletion of an SE ora federated resource,

FIGS. 9A-9B show the operation of a GDFPM if a new type of SE isprovided into the parts catalog; and

FIG. 10 shows an example of a dynamic free pool (DFP).

DESCRIPTION OF THE PREFERRED EMBODIMENTS

FIG. 2 shows provisioning of an SE according to the prior art. A newrequest 1 for an SE due either to a customer subscription or toincreasing workload on the provisioning system is generated. The newrequest 1 is propagated to the planner component 2 which handles the newrequest 1. The planner component retrieves the description for the SEfrom the parts catalog 3, builds the plan, and sends it to the runtimeengine for execution 4. The runtime engine executes the plan for therequested SE. It interacts with the required RMs 5 for the resourcesthat are required to build the SE. Each RM has its own static free poolfrom which it can take resources 5.

FIG. 4 shows an example of an SE, namely, a Secure WebServer SE whichwill be built up. The parts catalog contains the description of that SE;namely, it describes all resources which belong to the Secure WebServerSE. The Secure WebServer SE comprises a firewall (Firewall), a Webserver application (WebServerApp), an operating system (OS), andhardware (HW). Each resource is assigned an RM which will be theninvoked. The sequence in which they are invoked is defined in thedescription of the SE. The build plan defines the workflow, scripts andconfiguration actions to be taken to create the new SE.

FIG. 3 shows a prior art provisioning system with the inventiveextension. The inventive extension comprises the dynamic free pools(DFPs) 81, their respective DFP managers (DFPMs) 80, and a global DFPM(GDFPM) 90 which controls the overall operations by interacting with theindividual DFPMs 80.

DFPMs 80 and their associated DFPs 81 can be constructed and destroyedby the GDFPM 90 dynamically at runtime. The decision is based on thestate of the parts catalog 40, and the state of the provisioning system93 (SE instances and their state, state of the DFPs) and the policy theGDFPM operates on.

Now the functionality of the DFPM Interfaces is described.

A DFPM 80 is used to manage each one of the dynamically generated DFPs81. It extends the standard interfaces of a resource manager (RM) 60.Specifically, it provides the following interfaces:

Create returns a handle of a resource instance in the DFP 81. Theoperation fails if the DFP 81 is empty. This is similar to the RMinterface with the same name.

Delete gets a handle to a resource instance that was in use and returnsit to the DFP 81 (in some cases, described later, aggregated resourceswill be deconstructed to their basic resources and not returned to theirDFP). This is similar to the RM interface with the same name.

ChangeFPCapacity gets a new capacity number n. For a positive number nit provisions and adds n instances to the DFP 81. Otherwise itdeconstructed −n instances (returning the basic resources to theirstatic free pool).

In addition it provides the following static (class based) constructormethod:

Construct_DFPM gets a resource type description (a reference to a part)and an initial capacity and optionally a description of the requiredbehavior (in the form of policy). Construct a DFPM instance 80 and a DFP81 with the initial capacity.

In addition it provides the following static (class based) destructionmethod:

Destruct_DFPM destructs the DFPM instance 80 and the associated DFP 81.Deconstructs all the resources and return the basic resources to theirstatic free pools 50.

Now the dynamic generation of the DFPM and DFP is described.

The description below focuses on the case of an aggregate resource type,which is the most difficult case.

The role of the DFPM 80 is to manage a DFP 81 of aggregated resources(an example of a DFP is shown in FIG. 10). Management involves addinginstances of aggregated resources to the DFP 81 upon request orautomatically. The process of adding an aggregated resource instanceinvolves creating it by recursively creating its federated resources andconfiguring them together. The logic to create different aggregatedresource types depends on the resource type definition. The conditionsunder which it can generate dynamically (at runtime) DFPs 81 aredescribed below.

The workflow to create an aggregated resource from basic resources canbe generated dynamically by the planner component 20 from the definitionof the aggregated resource provided by the parts catalog 40. For everySE (represented as an aggregated resource) the planner component 20generates the following plans: (1) plans to create and destroy the SE;and (2) plans to create/add, and remove/destroy every “variable”federated resource to/from the SE (if defined as “variable”).

The planner component 20 can be used based on the same idea to generatefor every DFP 81 for an aggregated resource the following plans: (1) aplan to create an aggregated resource (and add to DFP), termedcreate_<resource_type_name>; and (2) a plan to destruct an aggregatedresource and return the basic resources to their respective DFP, termeddestroy_<resource_type_name>.

When a DFPM 80 is created by invoking its constructor Construct_DFPM,the implementation of the constructors calls the planner component 20 togenerate the aforementioned plans. A reference to the constructed plansis returned and kept in the new DFPM instance 80.

Whenever a new instance of an aggregated resource has to be created andadded to the DFP 81 (this can be either through the ChangeFPCapacitycall or when initially constructing the DFP 81), the create_< . . . >plan is executed the number of times required. If an instance has to bedestroyed the destroy_<. . . > plan is executed.

Now the operation of the DFPM 80 is described.

DFPMs 80 can operate in either a passive or an autonomic way.

A passive DFPM 80 serves requests to change capacity by invoking theplans as described above. It also serves create and delete requests byproviding a handle to an existing instance in the DFP 81 in the firstcase, and returning a handle of a resource instance to the DFP 81 in thesecond case.

An autonomic DFPM 80 can decide based on a policy to change the capacityof the DFP without an explicit ChangeFPCapacity request. An example of apolicy that can be used is a function that determines the requiredcapacity of the DFP based on total number of basic resources (that arefederated by this resource an aggregated), resource usage pattern, timeto provision, and other parameters.

Since the aforementioned behaviors are not related to a specificresource type they can be implemented separately and used in thedynamically generated DFPMs 80. The policy given as a parameter to theDFPM constructor method will determine which of the behaviors will beactivated.

Finally the operation of the GDFPM 90 is described.

The role of the GDFPM 90 is to manage the set of DFPMs 80. It receiveschange-of-state events including creation and destructions of SEs,change capacities of SEs, change in the total number of resourceinstances in the system, and also addition of resource type and SEdefinitions to the parts catalog 40.

Based on the events and the policy it operates on, it decides on dynamiccreation of new DFPMs 80, deletion of DFPMs 80, or a change in theircapacity. It uses the DFPM 80 interfaces in order to perform theoperations to fulfill the decision.

The GDFPM 90 can use known heuristics or optimization algorithms todecide on the required combination of DFPMs 80 and their capacity. Ituses the mechanisms described in this invention to carry out thedecisions.

The actual decision algorithm used depends on the objective function.Examples are the total revenue of the provisioning system owner or theamortized time for resources to be provisioned. The GDPFM 90 may alsowork with a more general arbiter component of the provisioning system.

The decision algorithm used may take into account the followingparameters for every resource: (1) revenue for allocation of theresource; (2) penalty if not allocated in time; (3) cost for having theresource in a running state (in the DFP or an SE); (4) time toprovision; and (5) usage patterns (how many, for what duration).

In a preferred embodiment of the present invention, the inventiveprovisioning idea may also be used for basic resources. This case ismuch simpler; the create interface of the RM 60 is used to provision theresource, which is then kept in the DFP construct (as shown in FIG. 1).

In another preferred embodiment of the present invention, the inventiveprovisioning idea may also be used for third party ownedresources/services. This case is similar to the previous one as a localRM represents such resources/services.

FIG. 5 shows method steps performed by the inventive GDPFM for creationof a DFPM.

A possible operation of the GDFPM is the creation of a DFPM. This may bedone as a reaction to a “state change event” propagated by theprovisioning system indicating, for example, that a new instance of aWebServer SE is needed (1).

The GDFPM may operate, for example, on a policy that forces the creationof a new DFPM whenever a certain number of requests for a certain SEhave been received.

The GDFPM interacts with the parts catalog to retrieve a description ofthe SE (3).

The GDFPM creates a DFPM by invoking the Construct_DFPM method of theDFPM class. The type WebServer SE is passed to this method. In addition,a policy may be specified to enable the DFPM to act autonomously. Anexample for such a policy would be: If the number of instances in thedynamic free pool is less than 5, then create another 2 instances orevery instance returned is to be decomposed (2).

The implementation of Construct_DFPM invokes the planner component (4.1)to create the plans needed to create a WebServer SE and also creates aninstance of a WebServer SE-DFPM together with its DFP (4.2). A referenceto the plan is kept in the DFPM instance (4.2).

After creating the DFPM instance, an instance of a WebServer SE can becreated by invoking the DFPM Create method (4.3).

FIG. 6 shows the method steps performed by the GDPFM for deletion of aDFPM according to the present invention.

The GDFPM receives a state change event from the provisioning system(1). This event may indicate that the last instance of the WebServer SEis to be destroyed. Operating on a policy defining “if the last SE is tobe destroyed, destroy all its DFPMs”, the GDFPM decides to destroy theDFPM (4). This is done by invoking the Destruct_DFPM method. The DFPMmight be itself policy driven (2): if the DFPM is destroyed, destroy allinstances of the DFP and return them to their DFPs (4.2). The planner isinvoked to build the destroy plan (4.1).

FIG. 7 shows the method of how to construct a plan for creation of an SEor a federated resource.

A request for generating a new SE or instantiating a federated resourcefor an already existing SE is received by the provisioning system, e.g.a state change event issued by an event handling component (not shown).

The event handling component propagates this event to the GDFPM. Then,the GDFPM calls the planner component, which generates a plan for thenew SE and for adding a federated resource to an existing SE. Thedescription for the SE is contained in the parts catalog. FIG. 4 showsan example of such a description of an SE which contains the variablefederated resource Secure WebServer. The WebServer itself may containthe variable federated resource Node. The DFPMs are generated by theGDFPM based on the GDFPM policy, e.g. generating DFPMs for everyvariable federated resource designed in the SE description or in thecase that an SE is currently not used to keep the DFPMs as well as theirassociated variable federated resources for later usage in a new SE.

The DFPMs are generated by the GDFPM by invoking Construct_DFPM. Theimplementation of Construct_DFPM invokes the planner component to createthe plans needed to create, for example, a Secure WebServer SE (see FIG.4) and also creates an instance of a WebServer DFPM together with itsDFP. A reference to the plan is kept in the DFPM instance.

The method of construction of plans to create a new SE or to add afederated resource to an existing SE is based on the sample flowdepicted in FIG. 7.

For every SE or federated resource (represented as an aggregatedresource) the planner component generates the following plans: (1) plansto create and destroy the SE or federated resource; and (2) plans tocreate/add, and remove/destroy every “variable” federated resourceto/from the SE (if defined as a “variable” resource).

At first the construction of a plan for creation of an SE or federatedresource is described with respect to FIG. 7.

-   -   1. A new SE (called R) or federated resource (called R) to an        existing SE is required.    -   2. Determine the set S of resources federated by resource R        (100).    -   3. For each member of S apply the following procedure, set forth        in subparagraphs 4 through 6 below (200):    -   4. If the member of S is a basic resource (300), then invoke the        RM of the member of S to create an instance of the basic        resource (400); if the member is no basic resource, then check        for the existence of a DFPM for the member of S (500). If one        exists call it to create the instance (600).    -   5. If no DFPM exists (700) then continue with the step set forth        in subparagraph 2 above until only basic resources are        available.    -   6. Add newly provisioned resources (federated variable or basic        resources) to the result set (800).    -   7. Configure each member of the result set (900).    -   8. Return result set to the caller (950), e.g. GDFPM or DFPM.

After creation of the DFPM instance, an instance of a Secure WebServerSE can be created by invoking the DFPM create method. This methodoperates on a plan constructed in way as described above.

Furthermore, a further plan for destruction of a new SE or federatedresource R, e.g. WebServer SE is generated. A destruction of a resourceR will apply for example when the SE or federated resource R is nolonger in use. The plan is generated by the planner component accordingto the following procedure as shown in FIG. 8:

-   -   1. Is there a DFPM for resource R (100)?    -   2. If yes, is resource R returnable (200)?    -   3. If yes, call DFPM to delete resource R from existing usage        environment (300) and return it to the DFP (300).    -   4. If not returnable, is R a basic resource (400).    -   5. If R is a basic resource call RM to delete instance (500).    -   6. If R is not a basic resource de-configure R (600).    -   7. If R is not a basic resource determine the set S of resources        federated by R (700).    -   8. Continue for each member of set S with step 1 (800).

FIGS. 9A-9B show the inventive provisioning of a new SE type.

A new SE type, e.g. Websphere WebServer, is added to the Parts catalog40 (1, 2). This addition in the Parts catalog creates an event that ispropagated to the GDFPM 90 (3). The GDFPM 90 retrieves the descriptionfor the new SE type from the Parts catalog 40. Based on its policy theGDFPM decides to create a DFPM 80 for the new SE type (4). All furthersteps are identical to FIG. 7 with the exception that no SE instancewill be created.

Now, a preferred implementation of the present invention is described.The preferred implementation describes a new method to provisionresources and SEs, de-provision resources and SEs, and transfer ofresources between SEs according to the present invention.

As described above the planner component generates a plan that isexecuted in order to provision a resource to an SE.

Now the prior art plan construction for provisioning a resource or SE isdescribed as a meta-flow:

Provision(R) For every R′ in Federated(R) // FEDERATED returns the listof federated // resources (the next level in the top. tree) If(Basic(R′)) // if the federated resource is basic get Next_inst =RM(R′).create( ) // it from its RM, else Next_inst = Provision(R′) //otherwise provision it // by calling the same method recursivelyFederatedList.add(Next_inst) // add to the list of federated resourcesFederatedList.configure(R) // configure all the resources in the listbased on the definition of R Return FederatedList

The planner component based on the actual definition of the aggregateresource completes the meta-flow to a provisioning plan. For example—theconfigure operation depends on the definition of R; its actualimplementation is generated by the planner component.

To leverage the DFPs constructions as taught by the present inventionthe provisioning meta-flow is changed such that a non-basic resource iscreated only if a DFPM for it does not exist; otherwise it is obtainedinstantaneously from the DFPM. The new meta-flow can be described asfollows (bold signifies the changes made):

Provision(R) For every R′ in Federated(R) If Basic(R′) Next_inst =RM(R′).create( ) else DFPM = DFPM(R′) // DFPM( ) returns a DFPM objectif it exists for R′ If (DFPM<>Null) Next_inst = // R′ is obtainedDFPM.create( ) from the DFPM else Next_inst = // recursive callProvision(R′) FederatedList.add(Next_inst) FederatedList.configure(R)Return FederatedListNew Method to De-provision Resources and SEs

When resources are de-allocated from an SE, they are deconstructedrecursively and the basic resources are returned to their respectivefree pools.

When using the DFP constructions sometimes there is no need todeconstruct the resources down to the basic resources or deconstructthem at all.

In principle, if a federated resource has a DFP, it does not need to bedeconstructed. Rather it is returned to the DFP using the deleteinterface of the DFPM. When doing that, some deconstruction processesmay include cleaning customer sensitive data, e.g., by disk scrubbing.

If the aggregated resource is going to be used later by a customer whohas strict security requirements (with respect to the customer thatreturned the resource) then the resource has to be deconstructed inorder to be cleaned.

To take advantage of the DFP constructions it is incorporated and used asecurity policy, which defines the pairwise security requirements forevery two SEs. (Security policy can actually be define for customers andinherited by SEs associated with these customers). If the securitypolicy between two SEs is relaxed then resources returned by one of themand given to the other do not have to be cleaned when relocatingresources between these SEs.

In order to take advantage of relaxed security, the GDFPM keeps track ofthe current potential set of SE “users” of every DFP. It can bedetermined that an SE is a potential “user” of a dynamic free pool fromits definition as an aggregated resource; if the Part that represent theresource pre-provisioned is a node in the topology tree of the SE thenthe SE is a potential “user” of the pool.

Now, if the pairwise security policy for all SEs that are potentialusers of a DFP is relaxed then the DFP is marked as “returnable”. Thismeans that aggregated resources can be returned to the DFP withoutdestruction. Otherwise it is marked as “non-returnable”, that means thataggregated resources are not returned to this DFP—they aredeconstructed.

The GDFPM updates the definition of each DFP as“returnable”/“non-returnable” as new SEs are provisioned, or existingSEs are de-provisioned.

The prior art meta flow for de-provisioning of an aggregated resourcecan be described as follows:

De-Provision(R) If Basic(R) RM(R).delete(R) // a basic resource isreturned to its RM Return De-configure(FederatedList(R)) // thisdestroys previously established relationships between // federatedresources For every R′ in Federated(R) De-Provision(R′) // recursivecall to de-provision an aggregated federated resource

The meta-flow according to the present invention for de-provisioning aresource is changed so that an aggregated resource is returned to itsDFP, if the DFP exists, and marked as “returnable”. The new meta-flowcan be described as follows:

De-Provision(R) DFPM = DFPM(R) If ((DFPM <> Null) AND // use a“returnable” DFP, Returnable(DFPM)) if it exists DFPM.delete(R) ReturnIf Basic(R) RM(R).delete(R) // we return a basic resource (w/o areturnable dynamic DFP) // to its RM for further proprietarycleaning/destruction Return // operations De-configure(FederatedList(R))// this destroys previously // established relationships // betweenfederated resources For every R′ in Federated(R) De-Provision(R′) //recursive call to de-provision a federated resourceNew Method to Transfer Resources Between SEs

The algorithms described above can be combined and enhanced to achievebetter results under various special conditions. Specifically, if thesecurity policy between two SEs is relaxed then resources can betransferred directly between them with out de-provisioning (includingcleaning) or even without returning them first to the DFP. Moreover,there may be several choices of an aggregated resource to transfer; asexplained below, different choices are preferred under differentconditions.

Handling a Resource Contention Condition

The idea is that if a basic resource is needed for an SE and is notavailable an aggregated resource can be relocated from a different SE.

Following is a description of a method to do that:

When a basic resource r, needed to construct an aggregated resource Rfor an SE S, is not available, find in the topology tree of R a node nrepresenting a resource r′ such that: (1) n is an ancestor of the leafthat represents r′ in the topology tree; (2) there exists an SE S′ thatcontains the resource r′ and it is defined “variable”; and moving r′from S′ to S will improve the overall state of the provisioning system(performance-wise or otherwise).

Security policy for the pair (S, S′) is relaxed.

Note that there may be a choice as to which ancestor node to choose.Different choices will yield better results under different conditions,as explained later.

The algorithm is changed so that instead of provisioning r recursivelyby provisioning its federated resources, or obtaining r from a DFP, itis relocated from the SE S′. Note that every SE is represented as avirtual resource that provides interfaces to reclaim “variable”resources.

It is not necessary to come up with one meta-flow that accounts for thispossibility. Rather, if a plan fails due to unavailability of a basicresource than a new plan is generated based on the algorithm describedabove.

Handling a Critical Time to Provision Condition:

If provisioning time is absolutely crucial and an aggregated resource ris not available in a DFP then the planner can choose to relocate theresource from a different SE instead of provisioning it. The decisionalso depends on whether federated resources of r are available in lowerlevel DFPs, or need to be provisioned. The actual provisioning time of aresource r relative to a certain provisioning system state (includingDFP states) is given by the following recursive expression:

If R available in a DFP or R is basic (C = infinity if C (some smallconstant) R is basic but not avail) Provision_time(R)=Configure_time(Federated(R)) + Otherwise Σ provision_time(R′) R′ in R

Once the provisioning time is calculated it can be determined whetherthe resource should be provisioned or relocated from an existing SE. Forexample, if provision_time(R)>critical_time, where critical_time isgiven as input, then the resource is relocated instead of provisioned.

Note that by fixing C to infinity (or just to a very large number) wecan unify both methods to handle the different conditions describedabove.

The algorithm can be further optimized: (I) to minimize the amount ofdisruption—if several basic resources are unavailable find a commonancestor to relocate in the topology tree; (2) to minimize the number ofresources that need to be relocated find the ancestor closest in thetree (lowest) that can be relocated; and (3) to minimize the time toprovision find an ancestor highest in the topology tree that can berelocated.

1. A method for provisioning of a new service environment (SE) or anaggregated resource for an existing service environment, comprising thesteps of: receiving, on a computer, a state change event for a newservice environment or aggregated resource for an existing serviceenvironment; propagating said state change event to a global dynamicfree pool manager; retrieving, on said computer, a description of saidnew service environment or said aggregated resource from a parts catalogand providing it to a planner component; creating at least one dynamicfree pool manager for said new service environment or said aggregatedresource based on a policy of said global dynamic free pool manager,said dynamic free pool manager executing on a server comprising hardwaremanaging an assigned dynamic free pool of aggregated resourcescomprising a federation of multiple related resources and a set ofrelationships between two or more of the related resources; generating,on said computer, a plan for construction of said new serviceenvironment or said aggregated resource by said planner componentcomprising the steps: determining a set S of resources included in saidnew service environment or said aggregated resource by using thedescription of said new service environment or said aggregated resource;applying for each member of the set S following procedure: invoking aresource manager of said member of the set S in order to create aninstance of said basic resource, in response to determining that themember of the set S is a basic resource; checking for the existence of adynamic free pool manager for said member of set S, in response todetermining that the member of the set S is an aggregated resource;creating a new instance for said member of the set S, in response todetermining that a dynamic free pool manager exists for the member ofthe set S; continuing with said determining step until only basicresources are available, in response to determining that the dynamicfree pool manager does not exist for the member of the set S; and addingnewly created resources to a result set; configuring each member of saidresult set; and providing access to said result set as part of said planto said dynamic free pool manager; creating an instance of said newservice environment or said aggregated resource by said dynamic freepool manager using said plan; and generating a plan for destruction ofsaid new service environment or said aggregated resource which comprisesthe steps of: calling said dynamic free pool manager to delete said newservice environment or said aggregated resource from said provisioningenvironment and returning it to an assigned dynamic free pool based ondetermining that a dynamic free pool manager exists for said new serviceenvironment or said aggregated resource and said new service environmentor said aggregated resource is returnable; determining whether theresource is a basic resource based on determining that said serviceenvironment or said aggregated resource is not returnable; calling anassigned resource manager to delete it based on determining that saidresource is a basic resource; and continuing for each member of said setS with said first step until only basic resources are available.
 2. Amethod according to claim 1, wherein the steps of generating the planfor destruction of said new service environment or said aggregatedresource further comprises the steps of: de-configuring said resourceand determining the set of resources included based on determining thatsaid resource is not a basic resource.
 3. A computer program productcomprising a non-transitory computer readable storage medium having acomputer program thereon for causing a computer to perform the method ofclaim 1 when said computer program is executed on a computer.